Reworked in c6b9100. Two force-pushes: the first (812b6a78b4d → 928f59d6363) is a plain rebase on main, the second (928f59d6363 → c6b9100d09c) is this review's changes only.

Python dependency removed. ComputeVersionTweak.py is deleted and the whole computation is CMake. You were right that my earlier reply conflated two things — the 3.11 floor is the wrapped-Python floor, and a native C++ build should not acquire an interpreter dependency at all. It no longer has one.

.git_archival.txt now takes priority over the git repo, as you suggested. It is read first; the file is only accepted if its describe-name is actually substituted, so upstream's committed $Format:$ placeholder is ignored and a working tree falls through to git describe. A fork that commits a substituted file gets exactly the behavior you described — it pins the upstream count from the fork point, and its own commits do not advance it.

Other caveats — the ones I think are real, stated plainly rather than buried:

1. Shallow and tagless clones report 0. git clone --depth 1 (and --no-tags) has no reachable tag, so git describe fails and the tweak is 0. This degrades quietly rather than failing the configure, but it means CI using shallow clones publishes 6.0.0.0. This is the most likely way to get a surprising value in practice.
2. The count is not a total order across branches. Two branches the same distance from a tag get the same tweak, so ITK_VERSION_FULL orders commits only within a linear history. Downstream gating on it is reliable against released tags, not between topic branches.
3. History rewriting changes it. A rebase or squash-merge changes the commit count, so the same logical change can carry different tweaks before and after landing.
4. It depends on the v[0-9]* tag convention being maintained and on tags being fetched.

Happy to take (1) further — e.g. warning at configure time when the tweak resolves to 0 in something that looks like a git checkout — if you think that is worth the noise.

@blowekamp The fixup based on your request has been completed.

Other caveats — the ones I think are real, stated plainly rather than buried:

1. Shallow and tagless clones report 0. git clone --depth 1 (and --no-tags) has no reachable tag, so git describe fails and the tweak is 0. This degrades quietly rather than failing the configure, but it means CI using shallow clones publishes 6.0.0.0. This is the most likely way to get a surprising value in practice.
2. The count is not a total order across branches. Two branches the same distance from a tag get the same tweak, so ITK_VERSION_FULL orders commits only within a linear history. Downstream gating on it is reliable against released tags, not between topic branches.
3. History rewriting changes it. A rebase or squash-merge changes the commit count, so the same logical change can carry different tweaks before and after landing.
4. It depends on the v[0-9]* tag convention being maintained and on tags being fetched.

Caveat #1 would not occur with the earlier suggested DATE method. The date of the last commit should still be in the .git_archive.txt file and the shallow commits. ( Note: when referencing SimpleITK I did not mean to suggest switching to the method of number of commits in SimpelTK).

Regarding caveat #2 and #3, the versioning would only be "valid" for release and main branches.

I think either method can work, it is just a matter of accepting and mitigating the limitation of such an automatic versioning system.

Thank you — that's the right refinement, and it makes the whole thing better. Swapped to the date method in 2e2c3bd0ad (that force-push is this change only).

You were right that caveat #1 was self-inflicted. git log -1 --format=%cd --date=short succeeds where git describe fails, so a git clone --depth 1 --no-tags now resolves to the real commit date instead of quietly publishing 6.0.0.0. And as you noted, node-date is already in .git_archival.txt, so tarballs are covered by the same field the archive substitution was going to carry anyway. Thanks also for the clarification that the SimpleITK reference was about the file mechanism, not about adopting commit counts — I over-read it.

The resolution order and the fork-pinning behavior you asked for are unchanged; only the value's provenance moved:

Still pure CMake, and the tweak still reaches only ITKConfig.cmake — itkConfigure.h has no TWEAK, so ccache is unaffected. find_package matching verified with a YYYYMMDD tweak: three-component exact still matches, older date compatible, newer date incompatible.

Agreed on your framing for the remaining limitations: the version is meaningful on main and release branches, and topic-branch ordering isn't something this should try to solve. The one genuinely new trade-off versus the count is granularity — two commits landing the same day share a tweak. For gating downstream baselines against released tags that seems clearly acceptable, but say the word if you'd rather have finer resolution.